System for exchanging medical information

ABSTRACT

A server-based system enables exchange of medical messages between users, monitors for a probability of communications breakdown likely to result in medical error, and instigates corrective actions to prevent communications breakdown from occurring. Monitoring may include whether a user has read or acted upon a message received within a specified timeframe and whether a user has specified routing preferences for delivering a message to a user better suited to read or act on the message. Corrective actions include the determination of and routing of messages to an optimal recipient and the generation of alerts to subsequent users where a message has not been read or acted upon within a specified timeframe.

BACKGROUND OF THE INVENTION

The present invention relates generally to a system for exchangingmedical information. More particularly, this invention relates to aserver-based system which effectively exchanges patient-related messagesbetween healthcare providers, prioritizes messages based on messagecontent, routes messages to optimal recipients based on messagingforwarding algorithms, monitors the read status of messages after theyhave been sent, alerts healthcare providers when a high priority messagehas not been read, and performs message analysis to determine if abreakdown in communication between healthcare providers is likely tooccur.

Communications breakdowns are one of the greatest causes of fatal andnonfatal medical errors in the United States. An estimated 200,000 fatalmedical errors occur each year, 70% of which are attributable to abreakdown in communications between healthcare providers. Many of thesecommunications breakdowns are systematic in nature; one in sevenmessages is sent to the wrong clinician, and thirty percent of allmessages go unanswered by the recipient. Furthermore, paging caninterrupt clinician workflows between ten and twenty times per hour,causing clinicians to spend more time processing communications thanperforming direct patient care. As such, healthcare providers often fearinterrupting physicians with pages even when a problem is occurring.

As a result, messages will often go undelivered, and many that aredelivered are ignored because the healthcare provider is not in aposition to read or act upon the message. Forwarding the message to ahealthcare provider who is in a position to read or act upon the messagetakes additional time and often requires contextual information notavailable to the sender or receiver of the message. Therefore, criticalmessages pertaining to a patient's healthcare often get lost amid thedin of digital communications, often resulting in fatal medical errors.

BRIEF SUMMARY OF THE INVENTION

In accordance with one aspect of the present invention, a web-basedsystem acts on behalf of the user (healthcare provider) to exchangepatient-related messages between healthcare providers, prioritizemessages based on message content, route messages to optimal recipientsbased on messaging forwarding algorithms, monitor the read status ofmessages after they have been sent, alert healthcare providers when ahigh priority message has not been read, and perform message analysis todetermine if a breakdown in communication between healthcare providersis likely to occur.

In an aspect of the system, messages sent between healthcare providersare analyzed for a likelihood of medical error resulting from abreakdown in communications. In another aspect of the system, routing ofmessages may be modified from an intended recipient to an optimalrecipient to prevent a likelihood of medical error resulting from abreakdown in communications.

In an embodiment, a server-based system for medical messaging enablesthe exchange of messages between users. The system comprises host systemeffective to process the delivery and routing of messages, a messagingdatabase effective to store a plurality of messages associated withpatients and healthcare providers, and an algorithm database effectiveto store a plurality of algorithms for processing said messages. Thesystem enables users to view and compose messages associated with amedical patient. The system enables users to access messages via anendpoint device whereby the system displays message informationassociated with the user through a user interface. The system transmitsnew messages composed upon the endpoint device to the host system,determines the optimal recipient for the message according to one ormore algorithms stored in the algorithm database, stores the message onthe message database, and notifies the optimal recipient of the message.The system additionally monitors the message status to ensure arecipient has viewed or acted upon the message and generates additionalnotifications to the optimal recipient or other users where a messagehas gone unviewed or without requisite action.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1A is a block diagram representing an embodiment of a systemaccording to the present invention.

FIG. 1B is a block diagram representing an embodiment of a secondportion of a system according to the present invention.

FIG. 2A is a flowchart representing on embodiment of a method accordingto the present invention.

FIG. 2B is a flowchart representing another embodiment of a methodaccording to the present invention.

FIG. 3 is a flowchart representing an embodiment of a login processaccording to the present invention.

FIG. 4 is a flowchart representing a series of steps for routing amessage to an optimal recipient according to the present invention.

FIG. 5 is a flowchart representing a series of steps for monitoring therisk of communications breakdown according to the present invention.

FIG. 6 is a flowchart representing a series of steps for creating apatient digest from associated messages according to the presentinvention.

FIG. 7 is a flowchart representing a series of steps for creating apatient safety analysis according to the present invention.

FIG. 8 is a flowchart representing a series of steps for creatingpatient analytics according to the present invention.

FIG. 9 is a modified screen shot representing an exemplary graphicaluser interface field according to the present invention.

FIG. 10 is a modified screen shot representing a second exemplarygraphical user interface field according to the present invention.

FIG. 11 is a modified screen shot representing a third exemplarygraphical user interface field according to the present invention.

FIG. 12 is a modified screen shot representing a fourth exemplarygraphical user interface field according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring generally to FIGS. 1-12, various embodiments of a system forexchanging medical information may be further described herein. Brieflystated, a messaging system in accordance with the present disclosureexchanges messages between healthcare providers and employs messagerouting and post-delivery message monitoring effective to reduce thelikelihood of communication breakdown. The message may be routed to anoptimal recipient that is different than the intended recipient based onthe intended recipient's routing preferences. The system may monitor thepost-delivery status of the message, including whether the message hasbeen read or if a recipient has responded to the message, and determinethat an alert should be generated to prevent the occurrence of acommunication breakdown that may result in medical error.

Where the various figures may describe embodiments sharing variouscommon elements and features with other embodiments, similar elementsand features are given the same reference numerals and redundantdescription thereof may be omitted below.

Throughout the specification and claims, the following terms take atleast the meanings explicitly associated herein, unless the contextdictates otherwise. The meanings identified below do not necessarilylimit the terms, but merely provide illustrative examples for the terms.The meaning of “a,” “an,” and “the” may include plural references, andthe meaning of “in” may include “in” and “on.” The phrase “in oneembodiment,” as used herein does not necessarily refer to the sameembodiment, although it may. Terms such as “providing,” “processing,”“supplying,” “determining,” “calculating” or the like may refer at leastto an action of a computer system, computer program, signal processor,logic or alternative analog or digital electronic device that may betransformative of signals represented as physical quantities, whetherautomatically or manually initiated.

Depending on the embodiment, certain acts, events, or functions of anyof the algorithms described herein can be performed in a differentsequence, can be added, merged, or left out altogether (e.g., not alldescribed acts or events are necessary for the practice of thealgorithm). Moreover, in certain embodiments, acts or events can beperformed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors or processor cores or onother parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules, and algorithm stepsdescribed in connection with the embodiments disclosed herein can beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. The described functionality can be implemented invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the disclosure.

The various illustrative logical blocks and modules described inconnection with the embodiments disclosed herein can be implemented orperformed by a machine, such as a general purpose processor, a digitalsignal processor (DSP), an application specific integrated circuit(ASIC), a field programmable gate array (FPGA) or other programmablelogic device, discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. A general purpose processor can be a microprocessor,but in the alternative, the processor can be a controller,microcontroller, or state machine, combinations of the same, or thelike. A processor can also be implemented as a combination of computingdevices, e.g., a combination of a DSP and a microprocessor, a pluralityof microprocessors, one or more microprocessors in conjunction with aDSP core, or any other such configuration.

The steps of a method, process, or algorithm described in connectionwith the embodiments disclosed herein can be embodied directly inhardware, in a software module executed by a processor, or in acombination of the two. A software module can reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, harddisk, a removable disk, a CD-ROM, or any other form of computer-readablemedium known in the art. An exemplary computer-readable medium can becoupled to the processor such that the processor can read informationfrom, and write information to, the memory/storage medium. In thealternative, the medium can be integral to the processor. The processorand the medium can reside in an ASIC. The ASIC can reside in a userterminal. In the alternative, the processor and the medium can reside asdiscrete components in a user terminal.

The term “user interface” as used herein may unless otherwise statedinclude any input-output module with respect to the hosted serverincluding but not limited to web portals, such as individual web pagesor those collectively defining a hosted website, mobile desktopapplications, telephony interfaces such as interactive voice response(IVR), and the like. Such interfaces may in a broader sense includepop-ups or links to third party websites for the purpose of furtheraccessing and/or integrating associated materials, data or programfunctions via the hosted system and in accordance with methods of thepresent invention.

The term “web-based network structure” as used herein may, unlessotherwise stated, refer generally to a platform effective to implementweb-transitory functions, whether browser-based or otherwise. In otherembodiments, the host system may within the scope of the presentinvention include other computer-implemented platforms and networksknown to those of skill in the art which are not web-based.

The term “communications network” as used herein with respect to datacommunication between two or more parties or otherwise betweencommunications network interfaces associated with two or more partiesmay therefore refer to any one of, or a combination of any two or moreof, telecommunications networks (whether wired, wireless, cellular orthe like), a global network such as the Internet, local networks,network links, Internet Service Providers (ISP's), and intermediatecommunication interfaces.

The term “healthcare provider” as used herein may refer to any person orgroup of persons who provide medical services associated with a patientincluding but not limited to clinicians, physicians, dentists,radiologists, optometrists, chiropractors, pharmacists, physicianassistants, nurses, dieticians, therapists, psychologists, emergencymedical technicians, and paramedics.

The term “user” as used herein may include for example individualhealthcare providers, a group of healthcare providers, a healthcarepatient/consumer/recipient/caregiver or may refer instead to any otherentity that may require access to the messaging system.

Referring first to FIG. 1, various embodiments of the host system 10 asdisclosed herein include a computer-readable medium 11 having programmodule 12 with processor-executable instructions embodied thereon. Themedium 11 may generally be effective to store data accessible to aprocessor 13 to which the medium 11 may be operatively linked. When themedium 11 is operatively coupled to a processor 13 the instructions maybe executed by the processor 13 to perform various functions recitedherein.

In an embodiment as shown in FIGS. 1A and 1B, a host system 10 includesthe medium 11 operatively connected to a processor 13 effective toexecute the instructions stored upon the program module 12. The medium11 and processor 13 may be communicatively coupled to one or more inputand/or output (I/O) devices 14. The I/O device 14 can include devices,for instance, but not limited to a modem for accessing another device,system, or network; a transceiver, a telephonic interface, a bridge, ora router. The I/O device 14 may be communicatively connected to one ormore databases including a message database 19 effective to store one ormore messages 27 associated with a patient 28, the messages comprisingcontent 29; and an algorithm database 20 effective to store one or morealgorithms 30 for processing the handling and routing of messages 27and/or message content 29. The I/O device 14 may further becommunicatively connected to third party databases 15 which may includean Admission, Discharge and Transfer System of an Emergency MedicalRecords database 16, one or more Call Systems databases 17, and a SingleSign-On Authentication database 18.

The host system 10 may be communicatively connected to one or moreendpoint devices 24 by means of a message bus 21. The message bus caninclude hardware or software bus network structure connections betweenthe host system 10 and the endpoint devices 24 and may be effective toexchange data across a firewall 22 that isolates the host system 10. Themessage bus may further facilitate a secure connection between theendpoint device 24 and the host system 10, the secure connectionincluding but not limited to secure socket layer (SSL) connection. Theendpoint device 24 may include a second non-transitoryprocessor-readable memory medium (hereinafter referred to as theendpoint memory) 26 having an end user application program 25 withprocessor-readable instructions embodied thereon. The endpoint memory 26may generally be effective to store data accessible to a second endpointdevice processor 27 to which the endpoint memory 26 may be operativelylinked. When the endpoint memory 26 is operatively coupled to the secondprocessor 27 the instructions may be executed by the second processor 27to receive data from the message bus 21. The instructions may beexecuted by the second processor 27 according to instructions providedfrom an external API 23 that exists outside the firewall 22 in relationto the host system 10. The external API 23 may exist on a demilitarizedhost 28 to which the endpoint device 24 is communicatively connected.The demilitarized host 28 may include one or more logical servers,physical computer servers, or combinations thereof. The endpoint devicemay be effective to provide data received from the message bus 21 andthrough the external API 23 to an end user application 25 stored uponthe endpoint memory 26.

An embodiment of a messaging method 200 may be described in associationwith the host system represented in FIGS. 1A and 1B herein with respectto FIG. 2A. The method 200 begins at step 201 by a user successfullylogging into the host system 10. In an embodiment, the user successfullylogs in by establishing a secure connection between an endpoint device24 and the host system 10, sending login credentials to the host system10, and having the host system 10 authenticate the login credentials andgrant access to the securely connected endpoint device 24.

Upon establishing a successful login, the host system 10 may present theuser with several options for interacting with the messaging system. Invarious embodiments, the user may choose to view one or more messagesassociated with the user as further defined in step 202. If the userchooses to view messages, the host system 10 may provide a list ofmessages with which the user is associated. The messages may beassociated to the user by being associated with patients with which theuser is associated. In various embodiments, some or all of theassociated messages may be presented along with their content through agraphical user interface as rendered by the end user application 25 ofthe endpoint device 24. In certain embodiments, messages may bedisplayed as a truncated list with a summary of message contentincluding the name of the patient with whom the message is associated,the date and time at which the message was sent, the title subject ofthe message, the priority of the message, and whether or not the messagehas been read.

A user may choose to create a message, whereupon the method 200 proceedsto step 203 by presenting the user with a message creation function. Incertain embodiments, the host system may present the message creationfunction through a graphical user interface as rendered by the end userapplication 25 of the endpoint device 24. The method 200 then proceedsto step 204 by determining a patient of the user's choice with whom toassociate the new message. In various embodiments, a user may bepresented with a list of associated patients. The host system 10 maydetermine the list of associated patients by requesting a list ofpatients from the electronic medical records system 16 and the messagedatabase 19. The host system 10 may combine the list of patientsdetermined from the electronic medical records system 16 and the messagedatabase 19 into a unified, non-redundant list to display to the user.This unified, non-redundant list may be streamed across the message bus21 to the user's endpoint device 24 in a transitory manner so that thelist may not be retained upon the endpoint device following terminationof the login session as described in step 201 above. In an alternativeembodiment, the user may choose a patient not initially associated withthe user from a list of all patients associated with the electronicmedical records system 16 and message database 19.

In one embodiment, the electronic medical records system may storeinformation regarding which users have accessed patient data through thehost system 10 in accordance with the method 200 as necessary to createa HIPAA audit log. The host system 10 may therefore forward accessinformation to the electronic medical records system 16.

Upon determination of a selected patient, the method 200 then proceedsto step 205 by determining one or more recipients for the new message.In various embodiments, the one or more recipients may be chosen from alist of healthcare providers associated with the selected patient. Thehost system 10 may determine the list of associated recipients byrequesting a list of healthcare providers associated with the selectedpatient from the electronic medical records system 16, the call systemsdatabase 17, and the message database 19. The host system 10 may combinethe list of healthcare providers determined from the electronic medicalrecords system 16, the call systems database 17, and the messagedatabase 19 into a unified, non-redundant list to display to the user.This unified, non-redundant list may be streamed across the message bus21 to the user's endpoint device 24 in a transitory manner so that thelist may not be retained upon the endpoint device following terminationof the login session as described in step 201 above. In an alternativeembodiment, a user may choose one or more recipients not initiallyassociated with the patient from a list of all healthcare providersassociated with the host system 10 and call systems database 17.

The user may then compose the message by populating the message withmessage content (step 206). In various embodiments, the user may composea message with content consisting of alphanumeric text characters. Inanother embodiment, the user may compose a message with contentconsisting of electronically stored audio, imagery, or video. In certainembodiments, the message content may include a message title subject, amessage body of content, and a message priority. The message prioritymay be selected from a list of predetermined priority levels. Thisselection may be made by the user or alternatively may be automaticallydetermined by the host system 10 from the message content according to anatural language processing algorithm stored on the algorithm database30. In an embodiment, the message composition may occur within the enduser application 25 on the user's endpoint device. The message contentmay be stored for purposes of composition on an external API 23 of ademilitarized host 28 so that none of the message content persists inthe endpoint memory 26 following termination of the login session asdescribed in step 201 above.

Upon completion of message composition, the method 200 then proceeds tostep 207 wherein the message is sent by the user. In an embodiment, themessage may be sent according to instructions sent from the user'sendpoint device 24 across a message bus 21 to the host system 10. Thehost system 10 may write the message 27 and message content 29 to themessage database 19.

The method 200 continues in step 208 by determining whether anyassociated routing preferences. In various embodiments, healthcareproviders may have associated routing preferences that determine optimalrouting procedures according to various criteria. Criteria may includedate and/or time that the message has been sent, the geospatial locationof the healthcare provider or the healthcare provider's endpoint device,the presence or absence of certain wireless communications networksvisible to the healthcare provider's endpoint device, and the priorityof the message. For example, a healthcare provider may have routingpreferences defined for when the healthcare provider is not on site atthe hospital to route messages to a healthcare provider on call. Inanother example, a healthcare provider may have routing preferencesdefined to receive messages of high priority during non-business hoursbut to route messages of low priority to an on-call physician or nurse.In an embodiment, a healthcare provider's routing preferences may bedefined by the healthcare provider. In an alternative embodiment, thehealthcare provider's routing preferences may be automaticallydetermined by the host system 10 according to one or more algorithms 30stored on the algorithms database 20.

Upon determination of the recipient's routing preferences, the method200 proceeds to step 209 by determining the optimal recipient for themessage. In various embodiments where a recipient has routingpreferences defined, the host system 10 determines the optimum recipientfor the message according to the selected recipient's routingpreferences. The routing preferences may be stored as one or morealgorithms 30 in the algorithm database 20, the call systems database17, or both. In an embodiment wherein the recipient does not haverouting preferences defined, the host system 10 may determine that theselected recipient is the optimal recipient for the message.

The method 200 continues to step 210 by sending the message to theoptimal recipient as determined prior in step 209. In variousembodiments, the host system 10 logically associates the message storedupon the message database 19 with the optimal recipient. The host systemmay send a notification to the optimal recipient regarding the existenceof the message on the message database 19. In an embodiment, the messagecontent is retained on the message server 19 and is streamed by the hostsystem 10 across a message bus 21 to an external API 23 to which theoptimal recipient's endpoint device 24 connects. The host system 10 maystream content in this manner in a transitory state so that none of themessage content persists in the endpoint memory 26 following terminationof the login session as described in step 201 above. Notification mayoccur by by direct notification through the system or by pushnotification through a third-party system. Examples of third-party pushnotification systems include but are not limited to Apple PushNotification, Android Push Notification, Parse, and Urban Airship.

The method 200 then proceeds to step 211 wherein the host system 10monitors the time elapsed since the message has been sent and themessage status. In various embodiments the message status may includewhether the message has been seen by the optimal recipient and whetherthe optimal recipient has responded to the message. The host system 10may additionally determine the priority of the message and one or moretime limits associated with the message priority for which the messagecan go unread or without recipient response. For example, a highpriority message may have a time limit specifying that the message mustbe read within 2 minutes since the message was initially sent and mustbe responded to within 5 minutes since the message was initially sent,whereas a low priority message may have a time limit specifying that themessage must be read within 24 hours since the message was initiallysent and may not have a time limit specifying the time by which therecipient must respond to the message. In an embodiment, the one or moretime limits are customizable.

The host system 10 compares the message status and the time elapsedsince the message has been sent to the one or more time limitsassociated with the message priority (step 212). In various embodiments,if the time elapsed exceeds the time limit for the message status, thehost system 10 will generate and send an alert (step 213). The alert maybe generated according to one or more algorithms 30 stored in thealgorithm database 20. The algorithms 30 may specify to generate andsend an e-mail to a specific user, place an automated phone call to aspecific user, or send a notification to a specific user according tothe various embodiments described in step 210. Alternatively, if thetime elapsed has not exceeded the time limit or if no time limit existsfor the determined message status, the host system 10 may cease themonitoring activities of steps 210 and 211 for that message.

A user successfully logged in according to step 201 may choose tospecify or update his or her routing preferences, wherein the method 200proceeds to step 214. In various embodiments, the host system 10 maypresent routing preferences update function through a graphical userinterface as rendered by the end user application 25 of the endpointdevice 24. The user may choose a trigger status (step 215) from a listof pre-defined trigger statuses, the trigger status determining when therouting preference should be effective to the host system 10 upon therouting of messages as specified above in step 208. The trigger statusmay include criteria such as date and/or time that an incoming messagehas been sent, the geospatial location of the user or the user'sendpoint device, the presence or absence of certain wirelesscommunications networks visible to the user's provider's endpointdevice, and the priority of an incoming message.

After a user has selected a trigger status, the method 200 continues tostep 215 by prompting a user for a subsequent routing action associatedwith the trigger status. The user may choose a routing action from alist of pre-defined routing actions. For example, a user may choose toroute messages received during a particular trigger status to a specifichealthcare provider. Alternatively, a user may choose a general routingfunction without a predefined recipient, whereby the host system 10 willdetermine the specific recipient at the time that the message is sent tothe user. For example, a user may choose to route messages to anattending physician on call, whereupon the host system 10 will determineat the time the message is sent to the user which specific healthcareprovider is the physician on call by querying the call systems database17.

The method 200 then proceeds to step 216 by committing and storing theupdated preferences. In various embodiments, when the user specifies forthe routing preference to be saved, the routing preference is translatedinto an algorithm to be stored upon the algorithm database 30 to bereferenced by the host system 10 such as during step 208. In oneembodiment, the algorithm may be sent from the endpoint device 24through the message bus 21 to the host system 10 to be stored by thehost system 10 on the algorithm database 30. In an alternativeembodiment, the algorithm may be determined, constructed, and storedonto the algorithm database 20 by the host system 10 from data receivedby the endpoint device 24.

A user successfully logged in according to step 201 may choose toperform patient analysis functions for a particular, wherein the method200 proceeds to step 218. In various embodiments, the host system 10 maypresent the patient analysis functions through a graphical userinterface as rendered by the end user application 25 of the endpointdevice 24. In various embodiments, the user may pre-select a patient forwhich the host system 10 will perform certain analytics. In alternativeembodiments, such as may be represented for example in FIG. 2B, the usermay choose the particular analytics function (steps 219, 224, 227) priorto determining the patient upon which the analytics function should beperformed. In another embodiment, the host system 10 may update the callsystems database 17 with the updated routing preferences.

If a user requests a message digest for a patient, the method 200proceeds to step 219 by forwarding the digest request from the user'sendpoint device 24 to the host system. The host system 10 may load fromthe algorithm database 20 a digest algorithm that instructs the hostsystem 10 in performing a message digest search.

The method 200 proceeds to step 220 wherein the host system 10 collectsmessages 27 and message content 29 from the message database 19. Invarious embodiments, the host system 10 processes only messages 27 andmessage content 29 associated with the selected patient. The method 200then proceeds to step 221 wherein the host system 10 performs analysison the collected messages according to the message digest algorithm todetermine the relative importance of the message. In variousembodiments, the algorithm dictates to the host system 10 to processmessage characteristics including message priority, the time at whichthe message was sent, the recipients of the message, and the messagecontent. The host system 10 applies the message algorithm to make aBoolean determination of the message importance according to the messagecharacteristics. The host system 10 may therefore flag a message asimportant or not flag a message as important. In various embodiments,the host system 10 will output a summary list of messages to the user.In an embodiment, the host system 10 may stream the summary list ofmessages across the data bus 21 to the endpoint device 24 for transitorydisplay via the end user application 25. The end user application 25 maydisplay the summary list of messages as sorted chronologically, sortedby message priority, or sorted by other message characteristicsidentified by the host system 10. In various embodiments, the end userapplication 25 may display flagged messages, non-flagged messages, or acombination thereof. In circumstances of a combined display, the enduser application may display flagged messages with more prominence thannon-flagged messages for easier identification of important messagecontent.

The method 200 then proceeds to step 222 by monitoring for user feedbackregarding the message flag categorization. In various embodiments, auser may override the flagging of messages as described in step 221. Forexample, a user may choose to flag a non-flagged message, therebyidentifying it as important, or may choose to de-flag a flagged message,thereby identifying it as unimportant. If the host system 10 receivesuser feedback in this manner, the host system 10 may analyze the digestalgorithm used to perform the analysis and modify the algorithm toimprove the sensitivity and specificity of future results incorporatingsaid algorithm (step 223). In an embodiment, the host system 10 mayadjust the relative weights of the specified characteristic variables toimprove flagging accuracy. The host system 10 may employ a machinelearning engine effective to improve the digest algorithm according touser feedback.

If a user requests a patient safety analysis (PSA) report for a patient,the method 200 proceeds to step 224 by forwarding the PSA report requestfrom the user's endpoint device 24 to the host system. The host system10 may load from the algorithm database 20 a PSA algorithm thatinstructs the host system 10 in performing the patient safety analysis.

The method 200 continues in step 225 by collecting patient data to beprocessed and displayed in the patient safety analysis report. Invarious embodiments, the host system 10 requests patient data from theelectronic medical records system (16) and message data from the messagedatabase (19). The host system 10 may request patient data includingpatient diagnoses, patient status, treating clinicians, and care-relatedevents associated with the patient. The host system 10 may requestmessage data including message content, total number of messages, thetime at which messages were sent, and healthcare provider participationin messages.

Upon receiving the requested data, the host system 10 analyzes the datain accordance with the PSA algorithm (step 226). Specifically, the hostsystem 10 may calculate the likelihood of that a communicationsbreakdown resulting in medical error will occur. The result of thisanalysis may be streamed to the user's endpoint device 24 for displayvia the end user application 25.

If a user requests patient analytics, the method 200 proceeds to step227 by forwarding the analytics request from the user's endpoint device24 to the host system. The host system 10 may load from the algorithmdatabase 20 an analytics algorithm that instructs the host system 10 inperforming the analytics.

The method 200 continues in step 228 wherein the host system 10 requestspatient data from the electronic medical records system 16 and messagedata associated with the patient from the message database 19.

The method 200 proceeds to step 229 wherein the host system 10 mayanalyze the data in accordance with an analytics algorithm stored on thealgorithm database 30. In various embodiments, the host system 10 mayperform various data transformations including identifying the number ofunanswered messages associated with the patient, graphing message volumeover time, summarizing message volume by type over time, and comparingthe volume of messages associated with the patient to a benchmarkvolume. The benchmark volume may be, for example, an ideal volume, anaverage volume, or another useful volume for comparison in determiningthe likelihood of a medical error occurring due to a breakdown incommunication. In certain embodiments, benchmark comparisons may be madeaccording to factors shared between other patients including thepatient's first listed diagnosis, the unit in which the patient islocated, the healthcare provider of the patient, and the day ofhospitalization of the patient. In an additional embodiment, the datatransformations may be made for more than one patient or healthcareprovider so as to identify general trends and outlier data indicating ahigher likelihood of medical error occurring. The data transformationsmay be streamed to the user's endpoint device 24 for viewing via the enduser application 25.

FIG. 3 demonstrates an example methodology for securely authenticating auser login from an endpoint device. The method 300 begins at a firststep 301 when a user executes the end user application 25 upon theendpoint device 24. The endpoint device 24 connects to the host system10 using a secured connection (step 302). In one embodiment the securedconnection may include a secure socket layer (SSL) connection to anexternal API 23 residing on a DMZ host 28 communicatively coupled to thehost system 10. In certain embodiments, connections may be madeaccording to but not limited to WebSockets protocols, Server-side eventsprotocols, or AJAX long-polling protocols. Once a secured connection hasbeen established, the method 300 continues in step 303 by sending arequest for login information over the secured connection to theendpoint device 24. In one embodiment, login information may include auser name and password associated with the user name.

The method 300 continues in step 304 by receiving the requested logininformation from the endpoint device 24 through the secured connection.The method 300 continues in step 305 by sending the received logininformation to an authentication server. In one embodiment, theauthentication server may be a third-party Single Sign-On Authenticationserver associated with multiple healthcare login systems. In analternative embodiment, the authentication server may be a subroutine ofthe host system 10.

The method 300 continues in step 306 by determining whether the endpointdevice 24 is authorized to access the host system 10 by comparing thelogin information received to credential data associated with theauthentication server. In one embodiment, successful authentication mayallow the endpoint device access to additional medical systems ordatabases not directly associated with the host system. If authorizationfails, the method 300 continues to step 307, by sending a rejectionnotice to the endpoint device and requests login information againaccording to step 303. Alternatively, if authorization is granted, themethod 300 proceeds to step 308, whereupon notice of authorization issent to the endpoint device 24.

The method 300 continues at step 309 by querying for messages associatedwith the user. In certain embodiments, the messages queried mayrepresent all messages associated with a user or alternatively mayrepresent only a subset of total messages associated with the user. Instep 310, the patient associated with each message and the informationassociated with each message may be determined. In one embodiment, theinformation associated with each message may include the patient name,the message subject, the message read status, the message priority, andthe message content for each message. The method 300 continues in step311 by requesting patient-specific information for each patientidentified in step 310. In one embodiment, the patient-specificinformation may be queried from an Emergency Medical Record system.Patient-specific information may include but is not necessarily limitedto patient's demographic information, patient's medical diagnoses,patient's medical care status, clinicians treating the patient, andcare-related events with which the patient is associated.

In step 312, the message information obtained step 310 and the patientinformation obtained step 311 is outputted to the authorized endpointdevice. In one embodiment, the data is streamed in a transitory stateeffective to prevent any of the message information from step 310 ormedical information from step 311 from persisting on an endpoint memory26 subsequent to termination of the login pursuant to the method 300.For example, the message information and patient information may bestreamed from the host system to an external API to which the endpointdevice connects for the duration of the authorized login sessionaccording to the method 300, and upon termination of the method 300, theendpoint device deletes all temporary files associated with the viewingof the message information and patient information.

The method 300 continues in step 313 by populating a graphical userinterface viewable by the endpoint device with the message informationand patient information. In one embodiment, the graphical user interfacemay arrange the message information chronologically as a list ofmessages. In another embodiment, the graphical user interface mayarrange the message information according to a list of patients withwhich the message information is associated. In certain embodiments, thegraphical user interface may include user-selectable message listshaving multiple methods of configuration, user-executable functions, anduser-viewable message data.

FIG. 4 is an example methodology for routing a message to an optimalrecipient. The method 400 begins at step 401 when a user requests froman endpoint device 24 for a new message to be created. Upon receivingthe request for a new message, the host system 10 identifies medicalpatients associated with a user (step 402). In certain embodiments,medical patients may be associated with a user where the user is aclinician for the patient. The method 400 continues in step 403 bydisplaying to the user a list of the identified patients. In certainembodiments, the user may choose one or more of the patients to whom themessage will pertain. Additionally, in certain embodiments, more thanone list of patients may be displayed. In an embodiment, the user maychoose instead to have all patients displayed including those notdetermined in step 402 to be associated with the user. In anotherembodiment, the user may search for a specific patient wherein the hostsystem 10 will display a list of patients associated with the user'ssearch terms.

Once the user selects the patient or patients with whom the message isassociated, the method 400 proceeds to step 405 by displaying a list ofhealthcare providers associated with the patient. In certainembodiments, the user may choose one or more of the healthcare providersas intended recipients of the message. Additionally, in certainembodiments, more than one list of healthcare providers may bedisplayed. In an embodiment, the user may choose to select a healthcareprovider not among the list of healthcare providers associated with thepatient. Selecting a healthcare provider in this manner may thereforeassociate the selected healthcare provider with the patient.

The method 400 continues in step 406 whereby the user composes amessage. In one embodiment, the user may compose a text message througha graphical user interface. In alternative embodiments, the user maycompose a voice message and/or a picture message. In another embodiment,the user may choose a priority level for the message. The priority levelmay be chosen from predetermined priorities such as “STAT,” “ASAP,”“When Possible,” or “FYI.”

The host system then determines whether the intended recipient hasrouting preferences (step 408). In an embodiment, an intendedrecipient's routing preferences are algorithms that define routingbehavior for the message given certain circumstances. For example, arouting preference may specify to route the message to an alternativerecipient if the recipient is within, or alternatively not within, acertain geospatial location. In certain embodiments, routing preferencesmay be defined according to the date, the time of day, and thegeospatial location of the user and/or the user's endpoint device 24.For example, a recipient's routing preferences may declare that incomingmessages should be routed to another recipient, such as the physician oncall, if the user's endpoint device 24 is physically located offhospital premises as determined by GPS coordinates, or as determined byvisibility of or connectivity to certain WiFi networks, or as determinedby visibility or connectivity to certain cellular network towers, or asdetermined by a combination thereof. In another example, a recipient'srouting preferences may declare that incoming messages should be routedto another recipient if the message has been sent at a specific date ortime, such as at 2:00 a.m. or on weekends. In a third example, arecipient's routing preferences may declare that only messages of acertain priority should be routed to the recipient and that messagesbelow the specified priority threshold should be routed to anotherrecipient.

In another embodiment, the routing preferences may be defined accordingto whether one or more wireless communications networks are visible tothe endpoint device 24 associated with the intended recipient. Inadditional embodiments, a recipient's routing preferences for receivingmessages may be defined by the recipient. Alternatively, or incombination therewith, a recipient's routing preferences may beautomatically determined through analysis of third-party systems incommunication with the host system 10. For example, a recipient'srouting preferences may be defined according to the recipient's hospitalcalendar, task list, or on-call schedule. In another example, arecipient's routing preferences may be defined according to forwardingprotocols as specified by the call systems databases, such as forwardingmessages to a specific individual or clinic or practice, or to anindividual or clinic or practice on call for the recipient, or to aservice line.

If the intended recipient does not have any routing preferences defined,then the method 400 proceeds to step 409 by routing the message to theintended recipient. In an embodiment, routing of the message associatesthe message with the intended recipient so that the intended recipienthas visibility to the message hosted on the message database 19. In anadditional embodiment, the intended recipient is notified upon receiptof the message by direct notification through the system or by pushnotification through a third-party system. Examples of third-party pushnotification systems include but are not limited to Apple PushNotification, Android Push Notification, Parse, and Urban Airship. Themethod then proceeds to step 412 further defined hereinafter.

Alternatively, if the intended recipient does have routing preferencesdefined, then the method 400 proceeds to step 410 wherein an optimalrecipient is determined. In one embodiment, the optimal recipient isdetermined according to the routing preferences of the intendedrecipient. The intended recipient's routing preferences may specify toroute the message to a specific individual, group, or practice. Theintended recipient's routing preferences may specify to route themessage to a general individual, group, or practice, whereby the hostsystem 10 may determine which specific recipient associated with theindividual, group, or practice is optimal for receiving the message. Inan embodiment, routing of the message associates the message with theoptimal recipient so that the optimal recipient has visibility to themessage hosted on the message database 19. In certain embodiments, themessage may also be associated with and/or visible to the intendedrecipient as well as the optimal recipient. In an additional embodiment,the optimal recipient is notified upon receipt of the message by directnotification through the system or by push notification through athird-party system. In certain embodiments, the intended recipient mayalso receive the same or similar notification. Examples of third-partypush notification systems include but are not limited to Apple PushNotification, Android Push Notification, Parse, and Urban Airship. Themethod then proceeds to step 412 further defined hereinafter.

Once the message has been routed to the intended and/or optimalrecipient, the method 400 proceeds to step 412 by engaging inpost-delivery monitoring of the message. In various embodiments,post-delivery monitoring includes determination of whether the messagehas been read by the intended and/or optimal recipient and whether theintended and/or optimal recipient has responded to the message. Responseto the message may include a subsequent message sent in reply or mayinclude performance of a specific action. For example, a recipient mayrespond to a message by scheduling an event associated with a certainpatient as determined by the host system 10. An example of a methodologyfor engaging in post-delivery message monitoring is further provided inFIG. 5.

FIG. 5 is an example of a methodology for monitoring the risk ofcommunications breakdown. The method 500 begins at step 501 when a usersends a message to a recipient. In one embodiment, the message isassociated with a recipient so that the recipient may view the messagefrom an endpoint device 24. The method 500 continues in step 502 whereinthe priority of the message is determined. In various embodiments, theuser who composed the message may specify the priority of the message.The priority may be selected from a list of pre-defined prioritystatuses. For example, a user may choose a priority level for a messageof “STAT,” “ASAP,” “When Possible,” or “FYI.” Alternatively, thepriority of the message may be determined by the host system 10 throughnatural language analysis of the message content. The host system maydetermine the priority of a message based on the presence of certainkeywords within the message content. For example, detection of thephrase “patient is coding” or “pt coding” may, according to one or morenatural language processing algorithms, warrant the host system todetermine a message priority of “STAT.” In an alternative embodiment,the message priority may be defined as null with no associated value.

Once the message priority has been determined, one or more time limitsare determined according to the message priority level (step 503). Invarious embodiments, one or more priority levels may have one or moreassociated time limits each for the maximum time the message may gounread or for the maximum time to which a message may go withoutresponse. A higher priority level may have a shorter time limit in whicha message must be read or responded to than compared to a lower prioritylevel. A lower priority level may have a longer associated time limit oralternatively no associated time limit. For example, a message with ahigh priority of “STAT” may have a response time limit of 2 minutes,whereas a message with a low priority of “FYI” may have no response timelimit and a read time limit of 24 hours.

The method 500 continues in step 504 wherein the host system 10 monitorsthe time elapsed since the message has been sent to the recipient.During this monitoring, the host system performs step 505 by determiningwhether or not the recipient has viewed the message. In one embodiment,the host system 10 may determine that the recipient has viewed themessage where the recipient has selected, clicked on, or otherwiseinteracted with the message as viewed through the end user application25 on the recipient's endpoint device 24.

If the recipient has not viewed the message, the method 500 proceeds tostep 506 by comparing the time elapsed since the message was sent to theread time limit associated with the message priority level as determinedin step 503 above. In one embodiment, the determined read time limit forthe specified priority level may be null, wherein the host system 10 mayeither continue monitoring the read status of the message or may ceasemonitoring the read status of the message. If the time elapsed has notexceeded the read limit, then the method 500 may continue to monitor thetime elapsed as further described above in step 504. Alternatively, ifthe time elapsed has exceeded the read limit, the host system 10 maydetermine an appropriate alert action according to one or morealgorithms 30 stored in the algorithms database 20. In certainembodiments, the algorithm 30 may specify to send an e-mail to a user,place an automated phone call to a user, or send a notification to auser. In further embodiments, the user may be predetermined according tothe algorithm 30 or alternatively determined and selected from aconnected call systems database 17. In further embodiments, anotification may include direct notification through the system or bypush notification through a third-party system. Examples of third-partypush notification systems include but are not limited to Apple PushNotification, Android Push Notification, Parse, and Urban Airship.

Once an appropriate alert action has been determined, the method 500proceeds to step 508 wherein an alert is sent according to the alertaction determined in step 507. In one embodiment, the host system 10 maycontinue to monitor the message according to step 504 following sendingthe alert in order to determine whether to send subsequent alerts. Forexample, if the time elapsed exceeds a second read limit, a second alertof an escalated priority may be triggered. For example, if a recipientfails to read a message in a determined amount of time followinggeneration of an initial alert, a subsequent alert may be sent to therecipient or to a physician on call so as to prevent the occurrence of amedical error.

If the recipient has viewed the message, the method 500 proceeds to step509 by determining whether the recipient has responded to the message.In various embodiments, the host system may determine that the recipienthas responded to the message by composing a new message associated withand in response to the first message. In another embodiment, the hostsystem 10 may determine that the recipient has responded to the messageby determining that the recipient has performed a subsequent action suchas scheduling an event, filling a prescription, or admitting a patient.

If the recipient has not responded to the message, the method 500proceeds to step 510 by comparing the time elapsed since the message wassent to the response time limit as associated with the message prioritylevel as determined in step 503 above. In one embodiment, the determinedresponse time limit for the specified priority level may be null,wherein the host system 10 may either continue monitoring the responsestatus of the message or may cease monitoring the read status of themessage. If the time elapsed has not exceeded the response limit, thenthe method 500 may continue to monitor the time elapsed as furtherdescribed above in step 504. Alternatively, if the time elapsed hasexceeded the response limit, the host system 10 may determine anappropriate alert action according to one or more algorithms 30 storedin the algorithms database 20. In certain embodiments, the algorithm 30may specify to send an e-mail to a user, place an automated phone callto a user, or send a notification to a user. In further embodiments, theuser may be predetermined according to the algorithm 30 or alternativelydetermined and selected from a connected call systems database 17. Infurther embodiments, a notification may include direct notificationthrough the system or by push notification through a third-party system.Examples of third-party push notification systems include but are notlimited to Apple Push Notification, Android Push Notification, Parse,and Urban Airship.

Once an appropriate alert action has been determined, the method 500proceeds to step 511 wherein an alert is sent according to the alertaction determined in step 507. In one embodiment, the host system 10 maycontinue to monitor the message according to step 504 following sendingthe alert in order to determine whether to send subsequent alerts. Forexample, if the time elapsed exceeds a second response limit, a secondalert of an escalated priority may be triggered. For example, if arecipient fails to respond to a message in a determined amount of timefollowing generation of an initial alert, a subsequent alert may be sentto the recipient or to a physician on call so as to prevent theoccurrence of a medical error.

If the recipient has responded to the message, the method 500 mayconclude at step 513 by ceasing the monitoring activities as specifiedabove in step 504. In an alternative embodiment, the host system 10 maycontinue to monitor the message for additional responses for purposes ofdetermining message analytics.

FIG. 6 is an example of a methodology for creating a digest of messagesassociated with a patient. The method 600 begins at step 601 when a userrequests a digest and the host system 10 receives such request. In oneembodiment, a user may request a digest by selecting a digest optionwithin the end user application 25 upon the user's endpoint device 24.In an alternative embodiment, the digest may be generated automaticallyor periodically and without user input.

Once the host system 10 has received a digest request, the host system10 may execute a search for all messages 27 stored on the messagedatabase 19 and associated with the patient for whom the digest wasrequested (step 602). In various embodiments, this search may beperformed by implementing a digest algorithm from the plurality ofalgorithms 30 stored upon the algorithm database 20. When all associatedmessages have been queried, the method 600 proceeds to step 603 byapplying a natural language processing algorithm to the messages 27 andassociated message content 29.

The method 600 continues in step 604 by analyzing whether all of theassociated messages have been analyzed with the natural languageprocessing. If not all associated messages have been analyzed, themethod continues to step 605 wherein the host system 10 determines theimportance of individual messages and content of messages by processingmessage characteristics. Message characteristics may include the messagepriority, the time the message was sent, the time elapsed since themessage has been sent, the recipients of the message, and the content ofthe message. If the host system 10 determines that the message isimportant, it will add a flag to the message (step 606). In variousembodiments, the flag may be visible in the end user application 25 inviewing the digest summary or the message directly. The flagged messageis subsequently added to the digest summary (step 607), and the hostsystem 10 then proceeds to the next message for processing (step 608).Alternatively, if the message is not deemed important, no flag is addedto the message, and the host system 10 proceeds to the next message asper step 608.

When all associated messages have been processed according to thenatural language algorithm, the method 600 proceeds to step 609 whereinthe digest summary is displayed, representing a collection of the mostimportant messages associated with the patient. In various embodiments,the digest summary may be displayed as a graphical user interface uponthe end user application 25 populated by the flagged message data asdetermined in step 606. The digest summary may be displayed as a list offlagged messages only or alternatively as a mixed list of flaggedmessages and non-flagged messages wherein the flagged messages havehigher visual prominence so as to distinguish them to the user. In anembodiment, the digest summary may be accessible to users not associatedwith the patient. For example, a nurse, doctor, or health care provideron rotation not otherwise directly associated with a certain patient maybe able to request and view a digest for that patient under his or herimmediate care.

The method 600 continues in step 610 by determining whether a flagoverride has occurred. In various embodiments, the initial determinationof a message flag according to step 606 may be overridden by the user.For example, a user may determine that message flagged as importantshould not be flagged as important, and may remove the flag from themessage, or alternatively may determine that an non-flagged messagedeemed unimportant is important and should be flagged. In certainembodiments, a user may override the initial determination of a messageflag according to step 606 by selecting or deselecting the message flagwithin the message list interface or digest summary interface of the enduser application.

If a user overrides a message flag in this manner, the method 600proceeds to step 611 wherein the host system 10 toggles the messageflag. In various embodiments, the toggle determination is Boolean,wherein a user may turn a flag for a message off or on. The method 600then proceeds to step 612, wherein the host system 10 analyzes thenatural language processing algorithm to determine how the naturallanguage processing algorithm's sensitivity and specificity may beimproved to ensure greater accuracy with future determinations ofmessage importance. In one embodiment, the host system 10 may improvethe natural language processing algorithm automatically throughapplication of a machine learning engine or by adjusting the relativeweight of the variables used to make the determination of messageimportance.

FIG. 7 is an example of a methodology for creating a patient safetyanalysis report associated with a patient. The method 700 begins at step701 when a user requests a patient safety analysis (PSA) report and thehost system 10 receives such request. In one embodiment, a user mayrequest a PSA report by selecting a PSA report option within the enduser application 25 upon the user's endpoint device 24. In analternative embodiment, the PSA report may be generated automatically orperiodically and without user input.

Once the host system 10 has received a PSA report request, the method700 proceeds to step 702 by requesting patient information. In variousembodiments, patient information may be requested from third-partydatabases 15 such as the electronic medical records database 16. Patientinformation may include patient demographics, patient diagnoses, patientstatus, clinicians treating the patient, and care-related eventsassociated with the patient such as hospitalizations, medicalemergencies, transfers, medical procedures, and releases. Patientinformation may additionally include insurance status, totalmedications, number of procedures planned, and ability or inability tocommunicate due to mitigating circumstances such as medication ordisease. In an embodiment, additional information may be collectedpertaining to the patient's health care providers such as providers'years of experience, caseload, types of cases within caseload, and hoursworked.

The method 700 proceeds to step 703 by requesting message informationpertaining to the patient. In various embodiments, message informationmay be requested from the message database 19 wherein the messages 27are associated with the patient 28. Message information may includemessage content, number of messages, priority of messages, the time atwhich the messages were sent, and clinician participation in messages.In an embodiment, additional information may be collected pertaining tothe healthcare providers' messaging such as number of communications perday, number of patient handoffs, and types of handoffs regarding sourceand destination department.

The host system 10 may then apply a PSA algorithm to the collectedpatient information and message information (step 704). The PSAalgorithm may predict a likelihood that a breakdown in communicationresulting in a medical error will occur. In one embodiment, the PSAalgorithm may be a logistic regression formula derived from dataassociated with the patient and the patient's health care providers. Insuch an embodiment, the logistic regression formula may be functionallyrelated to a Boolean determination of prior medical error havingoccurred from a communication breakdown. In another embodiment, theweight of analyzed variables may be changed or altered according to thelocation of the patient, location of the healthcare facility, orlocation of the system deployment.

FIG. 8 is an example of a methodology for creating patient analyticsreport. The method 800 begins at step 801 when a user requests a patientanalytics report and the host system 10 receives such request. In oneembodiment, a user may request an analytics report by selecting ananalytics report option within the end user application 25 upon theuser's endpoint device 24. In an alternative embodiment, the analyticsreport may be generated automatically or periodically and without userinput.

Once the host system 10 receives a request for a patient analyticsreport, the method continues at step 802 by requesting patientinformation. Patient information may include patient demographics,patient diagnoses, patient status, clinicians treating the patient, andcare-related events associated with the patient such ashospitalizations, medical emergencies, transfers, medical procedures,and releases. Patient information may additionally include insurancestatus, total medications, number of procedures planned, and ability orinability to communicate due to mitigating circumstances such asmedication or disease.

The method 800 proceeds to step 803 by requesting message informationpertaining to the patient. In various embodiments, message informationmay be requested from the message database 19 wherein the messages 27are associated with the patient 28. Message information may includemessage content, number of messages, priority of messages, the time atwhich the messages were sent, and clinician participation in messages.

The host system 10 may then apply an analytics algorithm to thecollected patient information and message information (step 804). Theanalytics algorithm may then perform various data transformations toprovide analytics upon the collected data. In various embodiments, theanalytics algorithm may perform the steps of identifying what and howmany of the messages associated with the patient are currentlyunanswered (step 806), graphing the volume of messages associated withthe patient over a function of time (step 807), summarizing the volumeof messages associated with the patient over a function of time based onmessage priority (step 808), and providing benchmarks regarding thenumber of messages associated with the patient against other patients inthe hospital system (step 809). These steps may be performedindividually or in any combination. In an additional embodiment, thehost system 10 may further perform regressions of step 809 by providingmessaging benchmarks based on patients who share the patient's firstlisted diagnosis (step 810), by providing messaging benchmarks based onpatients within the same medical unit location as the analyzed patient(step 811), by providing messaging benchmarks based on patients whoshare the same health care provider as the analyzed patient (step 812),and by providing messaging benchmarks based on patient who have beenhospitalized for the same number of days as the analyzed patient (step813). In one embodiment, the benchmarks of steps 809 through 813 mayprovide a percentage of analyzed patient's message volume versus theaverage message volume of the control group over a specific period oftime. In an additional embodiment, steps 809 through 813 may providemessaging benchmarks for a selected health care provider.

The method 800 then proceeds to step 814 by populating an analytics GUIwith the transformed data. In one embodiment, the analytics GUI isdisplayed upon the end user application 25 of the user's endpoint device24, the transformed data being streamed to the endpoint device in anon-persistent, transitory form. For example, the data may not persiston the endpoint device 24 after the session with the host system 10 isterminated. The transformed data may appear as one or more graphicscolor-coded to indicate threat metrics associated with a likelihood ofcommunication breakdown resulting in medical error. In anotherembodiment, the analytics GUI may display transformed data for multiplepatients within the same interface so as to allow the user to identifyrelative abnormalities that may represent a likelihood of communicationbreakdown resulting in medical error.

Referring now to FIGS. 1-8, in various embodiments the end userapplication 25 of the endpoint device 24 may generate a graphical userinterface for the displaying of messages, message content, and relatedmedia for interacting with the host system 10. An example of such anembodiment may be described further with reference to FIGS. 9-12.

FIG. 9 represents a default screen 900 whereby the user can performvarious messaging functions. In this embodiment, a main menu 901presents three selectable options whereby a user may choose to open amessaging interface 902, to request a patient digest 903, or open adirectory of users and/or patients 904. A second portion of the screenis populated with a list of recently received messages 905. In thisconfiguration, the messaging interface option 902 has been selected,resulting in a third portion of the screen being populated with a newmessage form 906. The user may choose a patient with whom the messagewill be associated 907, one or more recipients for the message 908, anda title subject for the message 909.

FIG. 10 represents a subsequent screen wherein the user has selected apatient 907 and may now select one or more recipients from an expandedlist of recipients 908. In an embodiment, the expanded list ofrecipients 908 may preferably be populated only with healthcareproviders associated with the selected patient 907.

FIG. 11 represents a subsequent screenshot wherein the user hasrequested a patient digest 903 from the main menu 901. A second portionof the screen is populated with a list of patients 910 associated withthe user. In this configuration, a patient has been selected, resultingin a third portion of the screen being populated with a digest summary911 of messages associated with the patient. In this embodiment, thesummary of messages is displayed as a chronological list whereinmessages are flagged as important 912(a) or are not flagged as important912(b).

FIG. 12 represents a screenshot of a patient analytics report. In thisembodiment, the name of the patient is displayed along with biographicand demographic information 913. Analytics pertaining to averageresponse times for various message priorities is displayed with anaverage time of response, a percentage of timely responses, and an iconof a color corresponding to the percentage of timely responses.Additional information effective to indicate a likelihood ofcommunication breakdown resulting in medical error may be displayed. Inthis configuration, additional information includes the number ofmessages unread or to which have not been responded separated intocategories by priority 914, a graph of the volume of messages pertainingto the patient over a period of time 915, and the volume of messagepertaining to the patient compared to an ideal benchmark as categorizedby benchmark type, time period analyzed, and message priority 916.

The previous detailed description has been provided for the purposes ofillustration and description. Thus, although there have been describedparticular embodiments of systems and methods according to the presentinvention, it is not intended that such references be construed aslimitations upon the scope of this invention except as set forth in thefollowing claims.

What is claimed is:
 1. A medical messaging system for exchangingpatient-related information, the system comprising: a non-transitorycomputer-readable medium having software residing thereon, the softwareexecutable by a processor to direct the performance of operations for:generating a user interface effective to enable a first user to submit amessaging request associated with a medical patient; identifying one ormore healthcare providers associated with the patient; generating uponthe user's request a message associated with the patient, the messagecomprising patient-related content; determining a recipient for themessage; applying a risk assessment algorithm effective to determine afirst value associated with a likelihood of communication breakdownassociated with the patient; comparing the first value to a second valueas a risk maximum threshold; and if the likelihood of communicationbreakdown exceeds the risk maximum, generating an alert associated withthe patient to an alert recipient chosen from the one or more healthcareproviders.
 2. The system of claim 1, wherein the risk assessmentalgorithm determines the first value by implementing: an elapsed timeassociated with the message, the elapsed time comprising a duration oftime since the message was generated; a read status associated with themessage, the read status comprising information pertaining to whetherthe recipient has viewed the message; and a time limit associated withthe read status.
 3. The system of claim 2, wherein determining the riskmaximum threshold further comprises comparing the read status and theelapsed time against the time limit.
 4. The system of claim 2, the riskassessment algorithm further effective to identify a message priorityassociated with the message, wherein one or more of the time limit andthe recipient are determined according to the message priority.
 5. Thesystem of claim 1, the software further executable by the processor todirect the performance of: identifying and classifying medicallysignificant information from the patient-related content; and combiningthe medically significant information into a template that is displayedwithin a graphical user interface.
 6. The system of claim 5, wherein thesoftware identifies the medically significant information by applying anatural language processing algorithm to the patient-related content. 7.The system of claim 5, the software further executable by the processorto direct the performance of enabling the recipient to override theclassification of the medically significant information.
 8. The systemof claim 1, the software further executable by the processor to directthe performance of: identifying and classifying messaging statisticsfrom the message; and combining the messaging statistics into a templatethat is displayed within a graphical user interface.
 9. The system ofclaim 8, wherein the messaging statistics are displayed within thegraphical user interface with respect to the likelihood ofcommunications breakdown.
 10. A medical messaging system for exchangingpatient-related information, the system comprising one or more computersconfigured to: identify a medical patient; identify one or morehealthcare providers associated with the patient; generate a messageassociated with the patient, the message comprising patient-relatedcontent; determine an intended recipient for the message; apply anescalation workflow algorithm effective to determine an optimalrecipient associated with the intended recipient; and deliver themessage to an endpoint device associated with the optimal recipient. 11.The system of claim 10, wherein the escalation workflow algorithm iseffective to determine the optimal recipient according to a routingpreference of the intended recipient, the routing preference comprisingdate data, time data, location data, and availability data.
 12. Thesystem of claim 11, wherein the one or more computers further configuredto determine the location data by identifying a wireless network visibleto the endpoint device, the wireless network chosen from at least one ofa wireless fidelity network or a cellular tower.
 13. The system of claim12, wherein the one or more computers are further configured todetermine the location data by identifying a set of GPS coordinates forthe endpoint device.
 14. The system of claim 10, wherein the escalationworkflow algorithm is further effective to determine the optimalrecipient by comparing the routing preference against routinginformation stored upon a call systems database.
 15. The system of claim10, wherein the one or more computers are further configured to updatethe routing information of the call systems database with the routingpreference of the intended recipient.
 16. The system of claim 10,wherein the message is accessible by the endpoint device using a securesession, and wherein the message does not persist on the endpoint deviceafter the secure session is terminated.
 17. A messaging systemcomprising: a perimeter communications network comprising a serverinterface for a plurality of user computing devices; a server networkcommunicatively linked to the perimeter network via a secure messagebus, the server network comprising a processor, a data storage networkand a non-transitory computer-readable medium having programinstructions residing thereon, the instructions executable by theprocessor to direct the performance of operations comprising: providinga user interface platform executable from the plurality of usercomputing devices, the user interface platform effective to enable usersto submit respective message routing preferences for storage in the datastorage network, and enable a first user to submit a messaging requestassociated with a medical patient, the messaging request defining a useras an intended recipient; in response to the messaging request,identifying one or more users as healthcare providers associated withthe patient; generating a message associated with the patient, themessage comprising patient-related content; determining an actualrecipient for the message from among the identified one or morehealthcare providers based at least in part on message routingpreferences associated with the intended recipient; applying a riskassessment algorithm effective to determine a first value associatedwith a likelihood of communication breakdown associated with thepatient; comparing the first value to a second value as a risk maximumthreshold, wherein if the first value exceeds the second, furthergenerating an alert associated with the patient to an alert recipientchosen from the one or more healthcare providers; calculating messagingbenchmarks associated with the patient based on expected messagingactivity for each of one or more user-selectable benchmark criteria; anduser-selectably generating a graphical representation of the calculatedbenchmarks with respect to actual messaging activity associated with thepatient, the graphical representation displayable on a respective userinterface platform.
 18. The messaging system of claim 17, wherein theuser-selectable messaging criteria comprises one or more of a patientcondition, healthcare provider, healthcare facility, and date ofadmission to a healthcare facility.
 19. The messaging system of claim17, wherein determining the first value further comprises: an elapsedtime associated with the message, the elapsed time comprising a durationof time since the message was generated; a read status associated withthe message, the read status comprising information pertaining towhether the recipient has viewed the message; and a time limitassociated with the read status.
 20. The system of claim 19, whereindetermining the risk maximum threshold further comprises comparing theread status and the elapsed time against the time limit.